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Catalog Publishing With FileMaker 


Data-Driven Layouts II 


By Mike Harris 

In my first article on data-driven layouts (in issue 
33) I talked about the techniques involved, using a 
catalog layout from the first Claris FileMaker Pro ad as 
an example. Since developing the necessary tricks, I 
have been looking for more applications that justify 
the trouble involved in creating data-driven layouts. 
For some reason, opaque to me, the mere fact that 
data-driven layouts are really cool, and illustrate im¬ 
portant basic FileMaker development tools, is insuffi¬ 
cient for some people. 

Iceland To The Rescue: 

A Database Publishing Problem 

The FileMaker Report recently got a letter from a 
subscriber in Iceland who has an interesting problem 
with a music catalog. See Figure 1. He wanted to be 
able to “mirror” header information when printing on 
both sides of pages. In this case he wanted to put page 
numbers and section headings to the left side of each 


“left-hand” page and to the right of each “right-hand” 
page. This is a typical requirement for page layout in 
books and, properly done, allows readers to thumb 
quickly through pages and see where they are. 

The FileMaker Report has considered some database 
publishing needs in previous issues (See “Printing 
Directories and Signature Imposition” in issue 23 and 
“Tab Leaders For Directories” in issue 14) and it 
occurred to me that there were particular database 
publishing problems in FileMaker which data-driven 
layouts could solve. So, using the music catalog from 
Iceland as an example, this article is a primer on cata¬ 
log publishing from FileMaker without resorting to a 
page layout program. 

The essence of a page layout program is detailed, 
custom control over text and graphics. At first glance, 
the printing structure of FileMaker - one layout which 
applies to all records currently printing - seems hope¬ 
lessly at odds with even a simple publishing task like a 
catalog. Data-driven text and graphics, however, allow 
you to specify in detail how pages and entries are 
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Note: 


Part 2 of this article will 
appear in the next issue. 


printed and, under ideal circumstances, 
allow the whole process to be completely 
automated. We consider in the two parts 
of this article three needs: gutters, headers 
/footers, and the assignment of special 
“layouts” for individual records. 


Mirrors 

Publishing anything but the most 
primitive catalog or directory requires 
double-sided page printing. Inside such a 
bound catalog, facing pages require, in 
several respects, different arrangements on 
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Figure 2 


their pages. For one thing, footers and 
headers often need to “mirror” each other: 
the page number and perhaps key infor¬ 
mation about the contents of the page 
need to be “outside” on each page to help 
readers navigate through the contents (see 
Figure 1 and the following section). It is 
also often necessary to have extra margin 
where the pages come together at the 
binding. Trouble is, of course, that this 
‘gutter’ alternates side from page to page. 

While there are ways to produce a gut¬ 
ter using two layouts (“left” and “right” 
layouts) to print alternate sides of pages, 
the process is tedious and easy to screw 
up. Instead, we are going to use data-driv¬ 
en tricks to shift the entire layout to the 
left or right depending on which page type 
the record occurs. 

The basic data-driven layout trick is: 
for each original field (which you want to 
be able to control) calculate one new field 
for each different layout position you re¬ 
quire. These calculations are controlled by 
values in each record. The result is that 
some fields calculate to values (and ap¬ 
pear) and others calculate to empty (and 
are invisible). By placing all these calculat¬ 
ed fields into one FileMaker layout, it is 


possible to have different records arranged 
completely differently on screen (and on 
print outs) depending on which fields are 
visible or invisible. 

For the simplest case of our music catalog 
we need to control six fields: Instrument, 
Group, Composer, Publisher, Title and 
Retail Price. Each is handled the same way 
and we need two new calculation fields for 
each. One calculation field appears in 
records on left-hand pages and the other on 
right-handers. 

For example, for the original field 
Instrument we need two new fields: 

InstrumentCalcL = {text result} 

if (Page Side = "L", Instrument, "") 

InstrumentCalcR = (text result) 

if (Page Side = "R", Instrument, “") 

Create two similar fields for each of the 
original six data fields. 

Gutter Layout 

Shifting the contents of an entire page 
to the left or right to produce gutters be¬ 
tween pages is a straightforward appli¬ 
cation of data-driven layout formulas. For 
our catalog we have two columns per 


Note 


GUTTER can be defined 
as the binding margin 
area on the "inside" of 
each page in a bound 
publication. Left-hand 
pages have the gutter 
on the right and right- 
hand pages have the 
gutter on the left. 


Convention 


When printing equa¬ 
tions, we use "" to 
mean quotes with 
nothing in between, 

" ^" as quotes with a 
soft space, and as 
quotes with a hard 
space. See page 15. 
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Figure 3 


Calculating Page Locations 

If we know exactly how many records fit on a page we can calculate which pages are lefties and which are 
righties. For our music catalog, we get 22 or 23 entries per page, depending on how many entries fall into 
each composer heading (Subsummary in FileMaker). So, we may write a new definition of the field Page 
Side, turning this text field into a calculation with a text result. To accommodate the one or two records 
which fall on the “wrong” page, we add a manual override field. Page Side Manual. 

Each record must have a number field which reflects the order of the Sort. This can be done by updating 
the field from an external text file, although this would have to be redone every time the file was sorted dif¬ 
ferently or records were added or removed. A calculated number which reflects the order of any current sort 
is best done with the new FileMaker Pro Summary function. Create a summary field which does a running 
count of some field which has a value in every record. We will use the Price field: 

Record Sequence = Count of Price (running) {summary} 

This Summary field will have a value equal to the number of the record in order of the current sort. Now 
convert this into a calculation field. Remember that a Sort by the “break field” Entry Record Number is re¬ 
quired to trigger this calculation. 

Record Number = Summary (Record Sequence, Entry Record Number) {numeric result} 

The “break field” in the equation above (Entry Record Number) can be any field which has a unique 
value in every record. All your FileMaker files need an auto-enter unique Entry Record Number field to be 
able to carry out some basic FileMaker tricks. (You do always create an Entry Record Number field in every 
file, right?) Now we need a Page Side Manual field and this calculation: 

Page Side = {text result} 

If (Page Side Manual > "a". Page Side Manual, If (Mod (Int (Record Number / 22),2) = 0 ,"L",''R")) 
Once implemented this scheme correctly calculates the page side of most records. Stray records can be 
corrected using Page Side Manual. When a new layout puts more or less records on each page change the 
divisor (“22”) in the Page Side formula. 
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page, which limits the potential dis¬ 
tance of a layout position difference |j 
to half of what it might be on a full 
page without columns. Still, there is 
sufficient room here to do what we 
need. j 

Our original layout created a larg¬ 
er margin on the right hand side of 
each page. This was done by choosing 
a column setup of 2 columns when | 

the page size was defined as a little I 

less than 8.5 inches wide (see Figure | 
2). The result, when printed on US j 

8.5 X 11 inch paper was a 1/2 inch left | 
margin and a 3/4 inch right margin. 
Assume we want about a 1 inch gut¬ 
ter. This implies a shift of 1/2 inch of all 
objects on the page when a page goes from 
left to right hand. 

Start with a new layout. Choose Blank 
as the type. In the File menu choose Page 
Set Up... and choose US Letter. In Layout 
mode choose Layout Options from the 
Layout menu. Choose ‘display in two col¬ 
umns, down first’ (see Figure 3). Notice 
that the columns now cover the entire 
width of the page (the vertical dashed lines 
of the page border and the right-most 
column edge nearly overlap). Using the 
wider columns gives us more maneuver¬ 
ing room to shift back and forth from left 
to right. 

Now place the calculated left and right 
hand fields on the layout. Since these 
fields will overlap in a confusing way — 
and since this layout will become more 
confusing as we go on to other effects - 
the best approach is to layout left and 
right hand fields on separate working lay¬ 
outs (see Figure 4 for the left working lay¬ 
out), then copy and paste the results onto 
the final gutter layout (Figure 3). This ap- 
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proach also makes any changes you may 
want to make to the layout later much 
easier. 

FileMaker Pro has some tricks which 
make copying an existing layout easy. 
Copy the original catalog layout, which 
was arranged for what we now are calling 
a “left” page, onto the working “left” lay¬ 
out. Now convert each old field into the 
new calculated “left” fields by holding 
down the option key and double clicking 
on each field in turn. FileMaker gives you 
a field dialog box which allows you to 
change the field instantly, while retaining 
the old format and position. Do this for 
each “CalcL” field. Now duplicate this 
preliminary left layout. Choose all the 
fields and move them as far to the right in 
the column as possible. Then, using op¬ 
tion double click, change all the fields to 
their appropriate “right” equivalents. 
When finished, duplicate one of the two 
preliminary layouts and copy the other 
preliminary layout fields on top. Figure 3 
shows the result. 

Now, each record needs to know 


Figure 4 


Illustrations of catalog 
pages with dot-line 
borders are showing the 
printable area. Actual 
print-outs have more 
margins on all sides that 
depend on the printer 
being used. FileMaker 
modifies layouts based 
on the printer currently 
selected in the Chooser. 
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Figure 5 


Tip 


Page layout effects can 
be easier and more 
varied using fonts which 
consist of graphics 
instead of letters. Look 
into "Art Importer" 
from Altsys and "Font 
Monger" from Ares. 
You will be able to 
'calculate' illustrations. 


whether it is on a left or right hand page. 
For advanced FileMaker users this can 
largely be handled with a calculation (see 
box: “Calculating Page Locations”). The 
purely manual method is not bad, how¬ 
ever. Place the appropriate value (“L” or 
“R”) in the Page Side field of each record. 
Looking at the catalog in Preview mode 
shows which records are on which pages. 
Note the first and last record on each 
page, find each page group using the usual 
FileMaker Find (or multiple-request 
Find) function and use Replace to put L’s 
and R’s in the appropriate records in 
groups. Figure 5 shows part of a page in 
Preview mode in which the Page Side 
field has been temporarily added for the 
purpose of spotting wrong-sided records 
(notice “Rode”). 

Mirror Headers 

While data-driven record layouts are 
pretty straightforward, it is not at all obvi¬ 
ous how to do the same with headers and 


footers. It seems at first glance that trying 
to control FileMaker header information 
in this way is surely impossible - how can 
you write calculation field formulas which 
control headers! After all, all record-based 
fields belong in the Body part, completely 
separate from the Header. Turns out, 
however, that when most non-summary 
fields are placed in the Header, their val¬ 
ues depend on the first record printed on 
that page. So, it is possible to use record- 
based data-driven tricks to mirror Header 
information on facing pages. 

The problem is complicated, however, 
by the fact that page numbering is not a 
field function in FileMaker - we can’t cal¬ 
culate page numbers the way we do text 
values. So we have to deal with the fact 
that the page number is an object that 
cannot “disappear” at our calculating 
whim. We might place the page number 
twice in each header, calculate a large 
“white text” character or look up a white 
square picture and alternately cover up 
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one or the other of the page numbers. In¬ 
stead, we are going to explore a more in¬ 
teresting use of the slide-left feature to 
beat this problem. 

We must have the following fields 
(note that InstrumentCalcL and Instru- 
mentCalcR were also used in the gutter 
problem above): 

Page Side 

InstrumentCalcL = {text result} 

if(Page Side = "L", Instrument, "“) 

InstrumentCalcR = {text result) 

if(Page Side = "R", Instrument, 

BlankRChar = {text result] 

iftPage Side = "R'',"a'',“'') 

(Note that “a” in the last equation 
above may be any character.) 


We want to end up with the page num¬ 
ber on the “outside” of each page, with the 
section heading - in this example the 
musical instrument - just inside the page 
number (Figure 6 shows the top of a right 
and a left hand page). To accomplish this 
requires understanding and using two of 
FileMaker’s “slide left” rules. The first rule 
is that objects slide left into the left-most 
field at their same level. The second is that 
only fields formatted with text alignment 
“left” slide. 

We place the objects in the header as 
follows, left to right (see figure 3): 

• BlankRChar - This field never has 
anything visible in it; instead it serves as 
the “left-most” slide stopping field for the 
fully-sliding left hand page. Without some 
field in this position, the header in figure 
6A would be in about the same position as 


Note 


My Icelandic is a bit 
rusty, but I suspect that 
"Fi>ia" = "Violin" and 
that "bis." is an abbrev¬ 
iation for "page". 
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More 


For additional informa¬ 
tion on a related sub¬ 
ject, see The FileMaker 
Report, issue 33, "A 
Data-Driven Layout" by 
Mike Harris. 


in figure 6B. 

• InstrumentCalcR - This field is text- 
aligned right; when it contains a value it 
stops all sliding left; this anchors the page 
number object to the far right and pre¬ 
vents the InstrumentCalcL field from 
appearing on the layout (although the 
field would be empty anyway in the 
“right-page” [Page Side = “R”] case). 

• Page number - In this case preceded 
by the abbreviation “bis.”, this layout text 
object slides left if allowed by the absence 
of a calculated value in InstrumentCalcR. 

• InstrumentCalcL-This field is text- 
aligned left and slides to the far left with 
the page number when InstrumentCalcR 
has no value. 

Figure 3 shows the layout which pro¬ 
duces the results illustrated in Figure 6. 
The far left field without an apparent 
name is BlankRChar. The name is invisi¬ 


ble because we have selected white for text 
color (see the Format menu) to allow this 
field to fulfill its slide-stopping function 
without cluttering the page with a mean¬ 
ingless character, the arbitrary letter “a” in 
this case. If our pages have a predictable 
number of records, a formula for auto¬ 
matically calculating Page Side (see box 
“Calculating Page Locations”) also makes 
header formatting automatic. 

Footers work exactly the same as head¬ 
ers, except they are driven by the last entry 
on the page rather than the first. 


In the next issue, part 2 of this article will 
consider how to develop a catalog file where 
each entry can be independently formatted 
with illustrations, borders, special type styles 
or banners. 


Running in Reverse 

When catalogs or booklets or manuals need to be presented two different 
ways - sorted, perhaps, both by composer and by instrument - it sometimes 
makes sense to print one sort version on one side of each page and the other 
version upside down on the other side of each page. The result is that the user 
ends up with two catalogs or booklets that are accessed just by turning a single 
publication around. It can be read from two directions. 

This is particularly appropriate with database publishing since the basic in¬ 
formation is the same, but is arranged differently - just what a database does 
nicely. It also makes the manipulation of headers, footers and gutters a little 
easier. 
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Q & A: Finding Old Customers 


By Mike & Joe 
The Answer Guys 


^ Here at our auto repair shop we 
^ have about 2000 customers but a 
FileMaker file of more than 5000 repair 
orders. We want to find all those custom¬ 
ers who have not been in for service in the 
last two months and print their names on 
mailing labels. 

- R. N., British Columbia 


^ This is one of those real-world 

problems it seems FileMaker ought 
to be able to handle quite easily. In fact, 
however, it is rather a challenge. Just for 
fun, readers might like to try to solve this 
problem themselves before reading fur¬ 
ther. We’ll be interested in different solu¬ 
tions that work at least as well as this one. 

The problem starts with the fact that 
we want to know something that can only 
be determined from groups of records. It is 
easy to divide all the service records into 
two groups: those before and after a given 
date two months ago. But then we need to 
extract a set of records from the before 
group that are not present in the after 
group. A non-trivial task. 

In our solution we group the records 
initially by customer. We need to look at 
all the repair orders for each customer and 
see if the last repair record for each cust¬ 
omer falls within the last two months. 

The FileMaker Find function is based 
on the contents of individual records, and 
cannot be used directly to ask questions 
about a group of records. For example, if 
we Find in the Service Date field for earli¬ 
er than two months ago, we end up with 
(a) a set of records containing multiple 
records for at least some customers and 


(b) a set of records which does not omit 
records of those customers also serviced 
one or more times later. 

Our solution uses two basic tricks: (a) 
group records by customer, determine the 
date of the most recent service and place 
that date in each of that customer’s service 
records; (b) use a subsummary to print 
only one address label for each customer 
regardless of how many service records 
each customer in the found group has. 

Step 1 - Get the date from the newest 
service record. 

We need to know the most recent date 
that each customer had service work. That 
can be obtained with a summary field that 
finds the maximum date in a group of 
records. With ServiceDate already a field, 
just define: 


Pro 


Trick (a) only works in 
FileMaker Pro. The new 
Pro Summary function 
opens the door to a 
wide range of neat stuff 
we couldn't do before. 


MaxDate = {Date Result} 

Maximum of ServiceDate 


Step 2 - Place the MaxDate value in 
each record. 

FileMaker Pro provides the new ability 
for summary field values to be placed into 
record-based calculation fields. Once in 
individual records, the summary values 
can be used for normal FileMaker func¬ 
tions. Define a calculation field: 


MaxDateCalc = {Date Result} 

Summary(MaxDate,LastName) 

Step 3 - Sort by customer LastName. 

The Summary function (as opposed to 
the summary field type - check the File- 


Q & A Motto 


"If it can't be done 
with FileMaker 
it's not worth doing!" 
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Hey! 


You got a problem? 
Maybe even a FileMaker 
problem? Send your 
question to The Answer 
Guys. If the problem is 
likely to interest other 
readers, we'll publish an 
answer here (if we have 
one!). Also send along 
questions with answers. 
Fame to follow ... 
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Maker manual for further confusion on 
this point) can only place summary field 
values in records when a Sort is per¬ 
formed which properly groups the records 
to be summarized. This requirement is 
similar to the requirement in FileMaker II 
that reports with subsummary parts have 
to be appropriately sorted before the sum¬ 
mary fields are calculated. This makes 
sense when you consider that a summary 
field figures some value over a group of 
records and we have to tell FileMaker - 
with a Sort operation - what groups are 
wanted. In this case, we want groups 
based on the customer, so we use the Last- 
Name field. 

In large files, the LastName may be 
insufficiently precise to distinguish 
uniquely every customer - there are likely 
to be several Smiths or Browns. In that 
case, a calculated MatchCode consisting 
of some combination of fields may be 
required - LastName & ZIP, or LastName 
& Firstinitial. Or different businesses may 
have unique information or coding to 
identify individuals. For an auto repair 
service the license plate or vehicle identifi¬ 
cation number should be unique and 
would serve as a good ‘break field’ for the 
Summary function. Whatever field is 
used, the principles described here remain 
the same. 

When you Sort by LastName, File¬ 
Maker Pro calculates the date of the most- 
recent service for each LastName and 
places this date in the MaxDateCalc field 
of each record. 

We now have the basis for a Find of 
customers who have not been in the shop 
for two months. 


Step 4 - Find all records with a 
MaxDateCalc field value earlier than 
two months old. 

This is easy enough: follow the usual 
Find process on the MaxDateCalc field. 
We have now found all the records of cus¬ 
tomers who have not had service in the 
last two months. 

The trouble is we have several records 
for many of the customers (remember in 
this file that one record = one service, not 
one record = one customer). We want to 
print one label for each of these found cus¬ 
tomers, without throwing away duplicate 
records. After all, the records really aren’t 
duplicates from the service invoice point 
of view. 

Step 5 - Print one label per customer. 

This is accomplished by making a 
normal label layout but substituting a 
Subsummary by LastName part for the 
usual body part used to specify the lower 
boundary of the label. If we Sort by Last- 
Name before printing from the layout, 
each label becomes a subsummary of all 
the records in the group defined by the 
LastName field. In short, each customer 
gets only one label printed, regardless of 
how often he or she appears in the found 
set. Bingo: the question is answered. 

Designing Databases 

Kim Hunter was the first to publish the 
subsummary label trick outlined above, in 
issue 10 of The FileMaker Report, page 5. 
Claris Tech Support has an Application 
Brief describing this in more detail. If you 
are a registered owner of FileMaker, call 
408-727-9054 and ask for “Auto-deleting 
and Omitting Duplicate Records”. 
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This Q & A brings up the importance 
of early design decisions when developing 
a FileMaker database. The questions; 
“What is a file?” and “What is a record?” 
need to be considered carefully in light of 
what you are likely to ask the database to 
do. If this design included, for instance, a 
Customer file (where one record = one 
customer) in addition to the Service In¬ 


voice file (where one record = one service 
invoice), the answer to this question 
might be quite different. 

Still, it’s great that FileMaker is flexible 
enough to allow solutions even when we 
don’t completely predict the future - it 
has saved us from acute embarrassment 
many a time! 


Data Entry Partners: 

Using Calculation and Data Fields Together 


By Mike Harris 

In a previous article (“Flaws Into 
Features”, The FileMaker Report, issue 29) 

I described several ways to use the limita¬ 
tions of repeating fields to advantage 
when designing FileMaker databases. This 
article takes a similar tack on an apparent¬ 
ly unavoidable characteristic of calculation 
fields: they won’t accept the cursor. 

In theory it seems a perfectly sensible 
way to insure that a calculation field al¬ 
ways reflects the current value of the de¬ 
fining formula. No cursor, no editing! 

The problem is sometimes you do 
want to override calculated values. Con¬ 
sider convenience text calculations. If you 


are calculating from upper-case names to 
proper name format, many names don’t 
come out quite right. Often only one or 
two letters need correction and the easiest, 
most natural way to do this would be to 
directly edit the calculated field. 

There is also the problem of untrained 
users. The quest for friendly interfaces is 
often confounded by confusion about the 
behavioral differences between calculated 
and data fields. 

(Never underestimate the importance 
of a friendly user interface. It is not simply 
that a beginner may need to use a file. Ac¬ 
curacy and speed are also affected by the 
quality of the interface. And if you are 
developing a FileMaker file for someone 


Other Reasons for Wanting The Cursor In Calculated Fields 

Placing the cursor in a field is required for operations other than entering and overwriting existing val¬ 
ues. You would like to be able to place the cursor in fields to: (1) highlight data so it can be copied to the 
clipboard, (2) View Index in browse mode, and (3) execute a Relookup command. Future articles will con¬ 
sider these needs. Calculated fields are used in FileMaker for broader purposes than just number arithmetic 
- calculation fields are where most of the “programmability” of FileMaker resides. So don’t accept any limi¬ 
tations without looking for workarounds. The payoffs can be substantial. 
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Tactics 


It is important (and 
more fun) not to accept 
the apparent limitations 
of FileMaker's features 
and functions. Often, a 
little thought shows the 
way to overcome a 
restriction or even turn 
it to your advantage. 


else, the perceived value of that template 
will be determined almost entirely by the 
ease of use.) 

A Basic Tool: The "If" Override 

In a certain sense it is possible to over¬ 
write a calculated field value. Suppose you 
have a typical calculation formula: 

Invoice Total = {numeric result} 

Subtotal Labor + Subtotal Travel + 

Sales Tax 


You can create a numeric data field 
called Invoice Settlement and rewrite the 
calculation with an “If’ function: 


Invoice Total = (numeric result) 

If (Invoice Settlement > 0, Invoice 
Settlement, Subtotal Labor + Subtotal 
Travel + Sales Tax) 

Thus you can change the value of the 
calculation field anytime by entering a 
value in Invoice Settlement. When 
Invoice Settlement is empty, the normal 
calculation is performed. 

That is straightforward enough and the 
general technique has been mentioned a 
few times in the past in The FileMaker 
Report. An overwrite field like Invoice Set¬ 
tlement can be placed on a layout near its 


Claris FileMaker Pro Technical Brief 

Auto-filled in Bill-To/Ship-To fields 

Consider the following scenario: Your invoice layout has separate fields for Bill-To name and address 
and Ship-To name and address. For most invoices, the Bill-To and Ship-To addresses are the same. So, 
you want to have the Ship-To address fill in automatically. However, you need to be able to enter a Ship- 
To address that is different than the Bill-To address. Here is a method that works. 

This example assumes that the following text fields exist in your database: BillToName, BillToAddress, 
BillToCity, BillToState, BillToZip, ShipToName, ShipToAddress, ShipToCity, ShipToState, ShipToZip. 

Define the following fields in your database: 

Field Name Type Description 

ShipTo Text Pre-defined List: "Same""Different"; Auto-Enter data: Same 

SameShipTo Calc (text) = If (ShipTo = "Same", BillToName & "SI "& BillToAddress & 

"SI" &BillToCity & BillToState & & BillToZip, "") 

(In the SameShipTo field definition above, you should type a space where you see the ^ character.) 

• Place the ShipTo field on your layout. Since most Ship-To addresses are the same as Bill-To, it is set 
to auto-enter “same” when you make a new invoice. It also has a pre-defined value list, so that you can use 
a pop-up menu or radio buttons to enter “same” or ’’different” into the field. 

• Place the SameShipTo field on top of the other ShipTo fields (ShipToName, ShipToAddress, etc.) 
With the SameShipTo field selected, choose Send Backward from the Arrange menu. This sends the Same¬ 
ShipTo field behind the other fields. 

• If the ShipTo field contains the value “Same”, the SameShipTo will contain the BillTo name and ad¬ 
dress. If ShipTo = “Different”, then SameShipTo will be blank, and you can fill in ShipToName, etc. 
which are on top of SameShipTo. 

- Copyright 1991 Claris Corporation. All rights reserved. 
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calculated companion and used at will. 
There are, however, as usual, additional 
possibilities... 

The ShipTo Address 

The box on page 12 presents the text of 
a Claris Technical Brief on the subject of 
ShipTo addresses. It raises the fascinating 
suggestion that calculated and related data 
fields can be placed on top of one another 
and can together behave like one field 
with compound properties. We will work 
through the problem somewhat different¬ 
ly than Claris. Their Tech Brief is meant to 
be a quick illustration of a basic idea. We 
consider here how this idea might more 
practically be applied to a working data¬ 
base. 

A distinction is often made, in large 
companies anyway, between billing (“Bill- 
To”) and shipping (“ShipTo”) addresses. 
Usually the ShipTo address is the same as 
the BillTo. So, you want the default 
arrangement to have both addresses the 
same without any further to-do. Where 
the ShipTo is different it would be nice to 
have an easy and intuitive way to change 
or enter the ShipTo address. 

It would also be nice if both cases 
could be done on the same Data Entry 
layout and if there were one set of fields 
which always contained the ShipTo ad¬ 
dress. This last requirement allows a Find 
(or other operation) to be done on a sin¬ 
gle set of address fields regardless of which 
type of record is involved. 

The Claris example, which works best 
when the main need is to produce labels, 
leaves the ShipTo address in one set of 
fields when ShipTo and BillTo are differ¬ 
ent, and concatenates one entirely differ¬ 
ent address field when ShipTo and BillTo 


Standard Field Names 


Over many years of small business consulting, I have de- 

veloped a standard set of address field names. This set is suffi- 

cient to cover every situation I’ve encountered although every 

field is not always used. Standardizing field names and types 

also enables a certain amount of useful file-to-file compatibil- 

ity. I commend these field names to you: 

Salutation 

(Text) 

Title 

(Text) 

First Name 

(Text) 

Middle Name 

(Text) 

Last Name 

(Text) 

Address One 

(Text) 

Address Two 

(Text) 

City 

(Text) 

State 

(Text) 

ZIP 

(Text) 

(yes, that’s right, ZIP 

should be a text field, trust me) 

ZIP Four 

(Text) 

Country 

(Text) 

Foreign ZIP 

(Text) 


are the same. 

Let’s start with our Basic Trick equa¬ 
tion, applied to each address field. For 
example for Address One, create a 
Manual ShipTo Address One field and a 
companion equation; 

ShipTo Address One = {Text Result} 
If (Manual ShipTo Address One > "a". 
Manual ShipTo Address One, MailTo 
AddressOne) 

Now place the Manual ShipTo 
Address One text field directly on top of 
the ShipTo Address One calculation field. 
(It may be necessary to use the “bring to 
front” command to make sure that 
Manual ShipTo Address One is really on 
top.) Make both fields the same size, font, 
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font size and font style. Make both field 
backgrounds transparent. 

The result is quite lovely. ShipTo Ad¬ 
dress One has the default value of MailTo 
Address One, a convenient property of 
calculation fields. It shows through the 
overlying but transparent Manual Ship To 
Address One which contains no value. 
This covers most cases. 

When the shipping address is different 
the operator can click on the space occu¬ 
pied by the overlapping fields. Since the 
Manual Ship To Address One field is on 
top, it accepts the cursor. Once the opera¬ 
tor begins typing, the underlying Ship To 
Address One field becomes whatever is 
typed into the overwrite field. Although 
both fields have data in them, the data is 
identical and overlaps perfectly. The effect 
is the apparent ability to overwrite the 
contents of a calculation field. Very neat. 
Repeat the calculation and layout for all 
your address fields. 


fields might be accessed, the operator is 
forced to go to the Customer file for ad¬ 
dress changes since the calculated address 
fields won’t accept the cursor. Using the 
Last Name field as an example (A 
CustomerCode field already exists): 

Last Name {text field, lookup} 

Lookup "Last Name" in "Customers" 
when "CustomerCode" matches 
"CustomerCode". If no match "Don't 
Copy". 

Last Name Calc = {text result} 

Last Name 

Now place only the Last Name Calc 
(and other equivalent address fields) on a 
data entry layout available to the operator. 
Using passwords, lock the operator out of 
any layout containing the original address 
data fields. It is now impossible for this 
person to change addresses in the Invoice 
file. 


Note 


The idea in the last 
section of this article 
about overlaying fields 
for telephone for¬ 
matting came from 
Claris Tech Support. 


A Flip of the Coin 

There are times when you want to pro¬ 
duce exactly the opposite effect: from that 
described above in order to prevent an 
operator from changing an address. Take 
the example of a Customer file and a re¬ 
lated Invoice file. The Invoice addresses 
are looked up from the Customer file as 
invoices are created, using a Customer- 
Code field. You would like any address 
changes to always be made in the Cus¬ 
tomer file, not in the Invoice file. How do 
you enforce this, especially with an opera¬ 
tor new to the database? 

If the data entry layout of the Invoice 
file uses only calculated address fields, and 
the operator is locked out (with a pass¬ 
word) of layouts where underlying data 


Flip Once Again 

Our ShipTo example considered times 
when you want a calculation field to re¬ 
flect the overwrite value of a data field. 
What about those times when you want a 
calculation field to predominate over a 
text field? 

When you enter a lot of names and 
addresses you may also enter a lot of 
phone numbers. Formatting the phone 
numbers as they are entered slows down 
data entry and can easily produce errors. 
Some database programs can be config¬ 
ured to automatically format phone num¬ 
bers from the entry of a simple number 
string. FileMaker does not have this for¬ 
matting built-in but can accomplish it 
using a variation of our trick. 
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Phone Number Raw {text field} 

(yes, text; trust me again) 

Phone Number Formatted = {text result) 
“{“ & Left (Phone Number Raw, 3) & ")" 
& & Middle (Phone Number Raw, 

3, 4) & & Middle(Phone Number 

Raw, 4,7) 

(Note that we are using the convention 
in printed equations that stands for 
double quotes with a space in between in 
the actual equation.) 

For ease of data entry, you want to 
overlap these two fields. There are two 
ways to do this. In the first, place identi¬ 
cally-formatted fields on top of each other 
with the calculation field on top this time. 
Select opaque (white) fills for the field 
backgrounds. To enter a phone number, 
tab into the Phone Number Raw field and 
enter your phone number as a simple 
string of numbers. The formatted phone 
number will magically appear in the calcu¬ 
lation field on top. 

If you need direct, mouse-click access 
instead of tab access to Phone Number 
Raw, make its field somewhat longer on 
one side or the other so you can place the 
cursor directly in the field. Center-align 
text for the field and no pieces of numbers 
will appear at the edges to mar the magic. 


Cosmological General Principles 

These examples illustrate one of the 
most important principles of FileMaker 
development and its compelling charms: 
imagination can be as important as tech¬ 
nical knowledge. Often if you can imagine 
doing something in FileMaker, the execu¬ 
tion is nearly trivial. What many times 
hangs us up is what we think we know 
what FileMaker can’t do. It is the differ¬ 
ence between the questions: “Does File¬ 
Maker do this?” and “Can FileMaker do 
this?” There are many apparent negative 
replies to the first question and very few 
real negatives to the second. 
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Convention 

There is a problem in the newsletter when we publish equations that require blank spaces as parameters. 
We need to show where the space is, of course, yet it may be difficult to see:"" and "" are very similar. And 
when we need multiple spaces, they are impossible to count on the paper (does " " represent 3 or 4 or 5 

spaces?). In the past we’ve put in text notes where necessary to explain such equations. 

Claris has been using a ^ symbol to represent a space and we are adopting that convention, plus adding 
one of our own. We’ll use ^ to mean a soft space (Space Bar), and ~ to mean a hard space (Option-Space 
Bar). Thus in an equation stands for double quotes with 2 soft spaces and has no spaces at all. -JK 
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with a release date of April, 1991. Previous versions of 
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